1. Field of the Invention
Embodiments of the present invention generally relate to bidirectional subscriptions. More specifically, embodiments of the present invention relate to a system and method for creating and managing bidirectional subscriptions as one transaction using Representational State Transfer.
2. Description of the Related Art
Computer-implemented collaborative and communication application programs, sometimes referred to as groupware, may be used by collaborative workers located at separate workstations to, for example, collaboratively prepare and/or review a computer-based document such as a word processing file, a presentation, a graphic file, a PDF, etc. An early example of such groupware was Lotus Notes. Such application programs rely heavily upon communication among collaborative workers using the applications. Such application programs commonly use inter-workstation messages such as sending subscription requests and receiving event notifications.
As more and more collaborative and communication application programs incorporate usage of the World Wide Web (“Web”) to communicatively connect collaborative workers, the ability to subscribe and receive event notifications in real-time on the Web is relatively more important. Several technologies have been developed to enable HTTP servers to push events to clients, including Bidirectional HTTP (e.g., Bayeux, BOSH and Server-Sent Events), and WebSockets. However, these technologies assume a client-server architecture and are not based on subscriptions. Without subscription, an event channel cannot be recovered after a server reboots.
RSS and Atom are two data formats that describe the published resources (i.e., feeds), including news, blogs and wikis, whose contents are updated by the content providers. The content providers syndicate the feeds on their web pages for the feed readers which fetch the updates by periodically polling the feeds. However, such polling is very inefficient in general, because the timing of the updates is unpredictable. Polling too frequently may waste a lot of network bandwidth, when there is no update. On the other hand, polling too infrequently may miss some important updates and incur delay on information processing.
To address the inefficiency of poll style feed delivery, a topic based subscription protocol called PubSubHubbub has been developed. In this protocol, a hub web server acts as a broker between feed publishers and subscribers. A feed publisher indicates in the feed document (Atom or RSS) its hub URL, to which a subscriber (a web server) can register the callback URL. Whenever there is an update, a feed publisher notifies its hub which then fetches the feed and multicasts (push) it to the registered subscribers. While this protocol enables more efficient push style feed updates, it does not describe how hubs can work cooperatively (i.e., be federated) to provide a global feed update service across different web sites. The protocol defines the unsubscribe operation by overloading POST which should have been DELETE—DELETE is idempotent and can be resubmitted but POST is not. Also the subscriptions are not modeled as addressable resources—if a subscription cannot be addressed, then it cannot be linked from other resources, which breaks the hypermedia constraint of REST.
Methods have been developed to provide asynchronous event delivery to web browsers, such as Ajax, Pushlet, Server-Sent Events and Web Sockets. However, these techniques are not applicable to federated notification services, where server to server relations and communication protocols are needed.
In software engineering, Publisher-Subscriber and/or Observer are software design patterns for keeping the states of cooperative components or systems synchronized by event propagation. They are widely used in event-driven programming for GUI applications. These design patterns have also been used for distributed computing, including Java Message Service (JMS), CORBA Event Service, CORBA Notification Service, which are not based on web services.
To further provide asynchronous event delivery, two event notification web services standards, Web Services Notification (“WS-Notification”) and Web Services Eventing (“WS-Eventing”) have been developed. However, these standards are not based on REST. Instead they are based on Web Services Description Language (“WSDL”) and Simple Object Access Protocol (“SOAP”), which are messaging protocols that are alternatives to REST.
WS-Topic is an industrial standard to define a topic-based formalism for organizing events. WS-Topic provides defines a mechanism to organize and categorize items of interest for subscription known as “topics” that are used in conjunction with the notification mechanisms defined in WS-Base Notification. However, these topics are not REST resources but are XML elements in some documents.
Event-Driven Architecture (EDA), with Service-Oriented Architecture (SOA), is used to enable agile and responsive business processes within enterprises. The fundamental ingredients of EDA are the following actors: event publishers that generate events, event listeners that receive events, event processors that analyze events and event reactors that respond to events. The responses may cause more events to occur, such that these actors form a closed loop.
The system model of the notification services is based on an overlay network of event brokers, including those based on DHT. There are two types of brokers: the inner brokers that route messages and the border brokers that interact with the event producers and listeners. A border broker provides an interface for clients to subscribe, unsubscribe, advertise and publish events. An event listener is responsible to implement a notify interface in order to receive notifications. However, no known notification systems are based on RESTful web services.
XMPP (RFC3920) supports efficient bidirectional XML streams between XMPP servers using two TCP/IP connections. This creates bidirectional notification flows between XMPP servers. However, XMPP protocol is not based on REST web services. Although BOSH (XEP-0124) uses HTTP long-polling to emulate bidirectional TCP streams, the established streams are not web resources that can be manipulated by HTTP. XMPP also supports a publish/subscribe extension (XEP-0060) to allow XMPP entities to subscribe and publish events to topics. But these subscriptions are unidirectional and not web resources.
Bayeux is a protocol that supports both HTTP long-polling and streaming mechanisms to allow a HTTP server to push notifications to a HTTP client. Although this protocol can be combined with normal HTTP request/response to support bidirectional notification flows, this combination only applies to client-server and cannot create bidirectional subscriptions.
Server-Sent Events defines a protocol that uses HTTP streaming to allow a HTTP server to push notifications to a HTTP client. Although this protocol can be combined with normal HTTP request/response to support bidirectional notification flows, this combination only applies to client-server and cannot create bidirectional subscriptions.
Google Wave provides near real-time state synchronization between web browsers that are in the same Wave session. Since Google Wave Federation Protocol is based on XMPP, it does not use HTTP to create or manage event subscriptions at all. Google Wave Client-Server Protocol is based on WebSockets and JSON. The protocol supports bidirectional notifications over a single TCP connection without subscriptions.
Microsoft Azure cloud platform has several built-in mechanisms to support EDA (Event-Driven Architecture), including server-to-server event subscriptions, for example between an event queue and a router. Azure support only the conventional unidirectional subscriptions.
To support subscription-based notification delivery between web servers, web-based event subscription protocols (e.g. WS-Notification, WS-Eventing, Google Subpubhubbub, etc.) have been developed to establish event channels between the web servers.
WS-Notification and WS-Eventing are two SOAP based web service standards that support server-to-server event subscription and delivery. Although these protocols can be transported over HTTP, they do not follow the constraints of REST. For instance, these protocols are not based on connected resources that support uniform interface. Furthermore, the subscriptions created by these protocols are unidirectional.
Google Pubsubhubbub (version 0.4) is an HTTP based protocol that supports server-to-server subscriptions as REST web services. It allows a subscriber (a web server) to subscribe to a hub (a web server) to receive updates on some topic. However, the subscriptions are unidirectional.
In these web-based event subscription protocols, a subscription represents an agreement between an event publisher and an event listener by which the event publisher agrees to send notifications, subject to a specified filter, to the event listener for an agreed time period, which may be indefinite. These web-based event subscription protocols only create unidirectional subscriptions such that notifications flow in one direction, i.e., from an event publisher to an event listener, hosted by a respective web server. Because notifications between web servers (or peers) may flow in both directions, two separate event channels, one to send and one to receive, are more efficient for asynchronous notification delivery.
When these two event channels are coordinated and have the same agreed time period, it is not efficient to use two unidirectional subscription transactions to manage them at least for the following reasons:
First, it is more difficult to coordinate two subscriptions with two transactions than with one, especially when the transactions involve multiple user credentials and servers;
Second, two subscription transactions have more network latency than one transaction.
Thus, there is a need for a system and method to create and manage bidirectional subscriptions as one transaction.